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1 Introduction of Stream Recording Format 

1.1 Purpose of the Specification 

This DVD Stream Recording Specification is defined to use rewritable DVD discs for 
recording existing digital bitstreams, editing them and playing them back as bitstreams. 
The Specification is designed to satisfy the following requirements: 

1.1.1 Service Requirements 

L L LI Individual Packet Size Support 

Any packet size should be supported as long as it is less than 2kByte and of constant 
length within a take. 

M.L2 Timing Regeneration 
iming mechanism (time stamp) needs to be added to every broadcast packet to enable 
proper packet delivery during playback. 

J. LI. 3 Non-real-time recording/download 

To enlarge the fields of applications, non-real-time recording should be possible. 
However, in this case the STB has to generate the Time Stamp information. 

LLL4 Data allocation strategy 

Data allocation strategy and file system need to be designed to support real-time stream 
recording. The solution, which will be specified in the RTRW activity, should be studied 
and adopted as close as possible. 

L L L 5 TOC and Service Information Support 

Many digital services require Service Information which normally is embedded in the real- 
time stream. To support the STB, DVD should provide additional space, which can be 
uyd by the STB to duplicate part of the service information and to add additional TOC 
i^»rmation. 

1,1.1.6 Copy Protection Support 

The Copy Protection rules are discussed in CPTWG and WG9. These rules must be 
supported. In addition any scrambling performed by the service provider or the STB must 
be kept unchanged. In a later stage some joint discussion with SW owners and service 
providers might be needed. 

1.1.2 User Requirements 

User requirements can be grouped into requirements for recording, requirements for 
playback, and requirements for editing. 

(Requirements for Recording) 

1.1.2.1 Real-time Recording 

The format should be designed to enable real-time recording of digital streams. It also 
should allow the user to concatenate recordings, even if those recordings consist of 




different stream formats. If recordings are concatenated, a (close to) seamless playback 
possibility would be nice but is not required. 



LLZ2 Total Recording Time 

Regarding the recording time, the conditions are very similar to the RTRW scenario. 
Therefore the same rules should be valid. In any case the user must be able to 
understand the situation and to take appropriate action, if needed. 

i.J-ZJ Navigation Support 

To support navigation two pieces of information (lists) should be generated during 
recording. 

An 'original' version of a play list . This list contains quite low level information, e.g. time 
map or (broadcast) packet order of the recording. This list is accessible by the STB and 
the content is understood by the DVD streamer as well as by the STB. In its 'original' 
version the playlist enables the playback of a complete recording. The playlist may be 
accessed and extended after recording by the STB to allow more sophisticated playback *W 
sequences. 

The second piece of information, mapping list is generated to support the stream 
recorder to retrieve packet stream chunks (ceils), that are described in terms of the 
application domain (e.g. 'broadcast packets 1 or 'time'). This list is owned and understood 
by the DVD streamer only. 

L 1.2.4 Content Description 

The format should reserve space, which can be used by the STB to store high level TOC 
and Service Information. This information is provided for the user to navigate through the 
content stored on disc and may contain sophisticated GUI information. The content is not 
needed to be understood by the stream recorder. However a common subset of the TOC 
information, e.g. based on a character string, may be useful to be shared between STB 
and DVD, in order to enable the stream recorder to provide a basic menu by itself. This 
may require some joint discussion with STB manufacturers, 

(Requirements for Playback) Q 

I. L 2. 5 Playback of individual recordings 

Needs to be supported; should be possible via play list 

LI. 2.6 Playing all recordings sequentially 

This is basically a set matter; should be possible via playlist. 
LI. 2. 7 Player menus for entry point selection 

This is mainly STB's responsibility, which can generate a sophisticated menu based on 
the TOC information stored on the disc. However, it should be possible to generate a 
simple menu by the streamer itself, e.g. via some 'character 1 information which is shared 
by STB and DVD. 

1.1.2.8 Trick play modes 

The STB should be able to steer trick play via the 'play list 1 . Due to the nature of the 
broadcast stream, the trick play features may be limited to basic ones, e.g. Time Search 
and Title Jump. 
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1.1.2.9 User defined PB sequences 

Features like playback programming or parental control can be supported via the play list 
1.1.2*10 Play list support 

The playlist must be supported as a key for all special playback and navigation. 
hU2.ll Play list creation 

The DVD streamer should create the 'original version' of the play list It also should allow 
extensions and modifications of the play list by the STB for more sophisticated playback 
features. The DVD streamer is not responsible for the content of those sophisticated 
playlist(s). 

(Requirements for Editing) 
MLZJ2 Delete single recordings 

me format must support the deletion of single recordings on user's request 

L 1.2.13 Delete parts of recordings 

If possible, the format should allow this feature under the control of the STB, However, 
complex processing and knowledge on the service may be required for this functionality. 

Ll.2.14 Inserting 

If possible, the format may support insert editing. This feature will probably require very 
complex processing and deep understanding of the service. An implementation, which will 
allow this feature, may be of semi-professional nature. 
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1.2 System Model 

This specification is based on the following overall system model: 



Application 
Device 



Buffering & 
Timestamping 



Buffering & 
Timestamp 
Handling 



IntertanPi 



(e.g. IEEE1394)' 




Figure 1-1 Overall System Model of DVD Stream Recording 
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1,3 Directory and File Structure 

The organization of Stream Data and Navigation Data of DVD Stream Recording is done 
in a specific way such as to take into account the following: 

• Any DVD Streamer Device has certain requirements to store its own "housekeeping" 
data on the disc. These data are solely for helping the retrieval of recorded data; they 
need not be understood or even be visible to any outside Application Device. 

• Any DVD Streamer Device needs to communicate with the Application Device it is 
connected to. This communication should be straightforward, and as universal as 
possible, so that the maximum possible range of applications - both today and future - 
can be connected to the Streamer. The Navigation Data to support such 
communication must be understandable by the Streamer as well as by the Application 

Device. 

^The Streamer Device should offer to the connected Application Device a means for 
Storing its own private data of any desired kind. The Streamer needs not to understand 
any of the content, internal structure, or meaning of this "Application Private Data". 

Figure 1-2 illustrates the directory and files where all the data comprising the disc content 
according to this Specification are recorded. All the files storing the disc content are 
placed under the STRREC directory. 

Root Directory 



■ STRREC Directory 

[COMMON.IFQ 

[STREAMER.IFO 

l APPL| CATJFO 

1 REALTIME.SOB 



Other Directories 

Other Files 

Figure 1-2 Directory and File Configuration 

Under the STRREC directory, the following files are created; 
• COMMON J FO 

Basic information to describe the stream content. Needs to be understood by the 
Application Device as well as the Streamer. 

0 STREAMER.IFO 

Private housekeeping information specific to the Streamer Device. Needs not to be 
understood by the Application Device. 

- APPLICATJFO 

Application Private Data, i.e. information that is specific to the Application(s) connected to 
the Streamer. Needs not to be understood by the Streamer. 
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* REALTIME.SOB 

Recorded real-time stream data proper. 

Note that except for the files described above, the STRREC directory shall not contain any 
other files or directories. 
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2 Navigation Data Structure 

Navigation data is provided to control the recording, playing back, and editing of any 
bitstreams that are recorded according to this Specification. As shown in Fig. 2-1 , 
Navigation Data consists of Stream Management Information (SMI) as contained in the 
file named COMMON. IFO and of Housekeeping Information (HKPI) as contained in the 
file named STREAM ER. I FO . 

From the point of view of the Streamer Device, these two kinds of information are 
sufficient to perform all necessary operations. Their details are described in Section 
"2.1 Streamer Relevant Navigation Data" below. 





Stream Manager 
General Information 
(SM„GI) 



Stream Title Table 
(STT) 



Stream Playlist Table 
(SPLT) 




Housekeeping 
General Information 
(HKP.GI) 



Housekeeping Address Table 
(HAT) 



Figure 2-1 Structure of DVD Streamer Navigation Data 

In addition to these, DVD Stream Recording also foresees the possibility of reserving a 
storage location for Application Private Data (APD), which may in general also be 
^isidered as Navigation Data. See Section u 2.2 Application Private Data" for Details. 

2.1 Streamer Relevant Navigation Data 

As explained above, SMI and HKPI are the Navigation Data which are directly relevant for 
the Streamer operation. 

SMI consists of three kinds of information tables, namely Stream Manager General 
Information (SM_GI), Stream Title Table (STT), and Stream Playlist Table (SPLT). These 
three tables shall all mandatorily be recorded and stored in the COMMON. IFO file in this 
order. 

HKPI consists of two kinds of information tables, namely Housekeeping General 
Information (HKP_GI) and Housekeeping Address Table (HAT). Both shall mandatorily be 
recorded and stored in the STREAMER. IFO file in this order. 



NB: Unlike in the "DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION", 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording. 




2.1,1 Stream Manager General Information (SM_GI) 



RBP 




Contents 


Number of Bytes 


Oto 9 


STRMG ID 


STRMG Identifier 


10 


10 to 11 


reserved 


reserved 


2 


12 to 15 


SMI EA 


End address of SMI 


A 


16 to 27 


reserved 


reserved 


12 


28 to 31 


SMGI EA 


End address of SM Gl 


4 


32 to 33 


VERN 


Version number of DVD Streamer 

opecmcations 


2 


34 to 127 


reserved 


reserved 


94 


128 to 129 


TM ZONE 


Time Zone 


2 


130 to 191 


reserved 


reserved 


62 


192 to 195 


STT SA 


Start Address of STT 


4 


196 to 199 


SPLT SA 


Start Address of SPLT 


4 


200 to 51 1 


reserved 


reserved 


312 



Total 512 



(RBP 0 to 9) STRMG J D 

Describes "DVD_STR_MG" to identify Stream Recording Management Information File 
with character set code of IS0646 (a-characters). 

(RBP 12 to 15) SMI_EA 

Describes the end address of SMI with RLBN from the first LB of this SMI. 
(RBP 28 to 31) SMGl.EA 

Describes the end address of SM_GI with RBN from the first byte of this SM_Gl. 
(RBP 32 to 33) VERN 

Describes the version number of this Specification. 




Book Part version ... 0000b 0001b: version 0.1 

Others: reserved 

(RBP 128 to 129) TM.ZONE 

Describes the Time Zone for this Disc. All fields related to "Recorded Time" share this 
Time Zone value. The detailed structure for TM_ZONE is TBD. 

(RBP 192 to 195) STT_SA 

Describes the start address of STT with RBN from the first byte of this SM_GI. 
(RBP 196 to 199) SPLT_SA 

Describes the start address of SPLT with RBN from the first byte of this SM_GI. 
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2,1-2 Stream Title Table (STT) 



Stream Manager 
General Information 



Stream Playlist Table 
(SPLT) 



• 




Figure 2-2 : Stream Title Table 



21.21 Stream Title Table General Information (STTJGT) 





Contents 


Number of Bytes 


(1) ST Ns 


Number of Stream Titles 


2 


(2) STT EA 


End Address of Stream Title Table 


4 


(3)STN CHRS 


Stream Title Name Character Set 


1 




Total 


7 



^TST_Ns 

Describes the number of Stream Titles, which are described in this STT. The maximum 
allowable number of Stream Titles is 999. 

(2) STT_EA 

Describes the End Address of Stream Title Table with RBN from the first byte of the STT. 
(1)STN_CHRS 

Identifies the character set used for the Stream Title Names (STNs) in this STT. Details 
are TBD. 

2.1.2.2 Stream Title Entry (STE) 





Contents 


Number of Bytes 


(DAP PKT SZ 


Application Packet Size 


2 


(2)SRV ID 


Service ID 


1 


(3)AP DEV ID 


Application Device ID 


12 


(4) ST.DUR 


Stream Duration 


6 


(5) ST NM SRP 


Stream Name Search Pointer 


4 




Total 


25 



(1) AP_PKT_SZ 

Describes the Application Packet Size in bytes. This packet size is valid for the entire 
stream title. 

NB: Due to the minimum transfer rate restriction rules described in Section „??", 
know/edge of the AP_PKT_SZ does not automatically and not for all streamer packets 
imply how many application packets are grouped together into the streamer packet 

(2) SRVJD 

Describes an identifier of the digital service which created the stream of this title. Details 
of the identifier are TBD, 

(3) APJJEVJD 

Describes an identifier of the application device that was physically delivering the stream 
of this title. Details of the identifier are TBD. 

(4) ST_DUR 

Describes the duration of the stream of this title, as resulting from the difference between 
the extended SCR of the last application packet of the stream minus the extended SCR of 
the first application packet of the stream. For the definition of Extended SCR, see 
Section „??". 

(5) ST_NM_SRP 

Describes the start address of the name string associated with this stream title, with RBN 
from the first byte of the STT. Name sharing shall not occur, i.e. each of the 
ST NM SRPs of the stream titles shall point to a different stream title name. 



2.1.2.3 Stream Title Name (STN) 





Contents 


Number of Bytes 


(1) ST NAME 


Stream Title Name 


variable 



(1 ) ST_NAME 

Describes the Stream Title Name as a variable length string of characters from the 
character set identified by STN_CHRS of STT_Gl. 



;;p||tii;l|||||||||::; 



IHK^MB'^ 8 17=10 

-BVB- 



TCE PfiTl 

TCE 



<■v•wA■.v■"-■■^^*••••-^fr>^;*wx^■^^^^^^■c■K•^c•K■^^> 

TS GERltf" — : 




_ _ ' I^".'— V*J /JA'AWAW-WiW. 1 .'.','. 1 .'.* 



Sdential? 



2-1 J Stream Playlist Table (SPLT) 



Stream Manager 
General Information 
(SM_GI) 



Stream Title Table 
(STT) 
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Figure 2-3 : Stream Playlist Table 

ZL3.1 Stream Playlist Table General Information (SPLT_GI) 





Contents 


Number of Bytes 


(1)SPL Ns 


Number of Playlists 


1 


(2) SPLT_EA 


End address of SPLT 


4 


(3)SPLN CHRS 


Stream Playlist Name Character Set 


1 




Total 


6 



(1) SPL_Ns 

Describes the Number of playlists described in this SPLT. The maximum allowed number 
Aplayiists is 99. SPLJMs also informs, how many SPI_SA and associated SPI are 
included in this SPLT. 

(2) SPLT_EA 

Describes the End Address of this SPLT with RBN from the first byte of this SPLT. 

(3) SPLN_CHRS 

Identifies the character set used for the Stream Playlist Names (SPLNs) in this SPLT. 
Details are TBD. 



Z 1.3.2 Stream Playlist Search Pointer (SPJSRP) 





Contents 


Number of Bytes 


(1)SPI SA 


Start Address of Playlist Information 


4 



(1) SPI_SA 

Describes the Start Address of the corresponding Stream Playlist Information, with RBN 
from the first byte of this SPLT. 
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2.1.3.3 Stream Playlist Information (SPI) 





Contents 


Number of Bytes 


(1) PE .Ns 


Number of Playlist Entries 


2 


(2)SPL CREATE_TM 


Creation Time of this SPL 


5 


(3)SPL NAME 


Stream Playlist Name 


variable 



(1) PE_Ns 

Describes the Number of playlist entries of which this playlist consists. The maximum 
allowed number of playlist entries per playlist is TBD. PE_Ns also informs, which and how 
many of the subsequent PEs belong to this playlist. 

(2) SPL_CREATE__TM 

Describes the creation time of this playlist in STRR's Date and Time Describing format 
TBD. 

(3) SPLJMAME 

Describes the Stream Playlist Name as a variable length string of characters from the A 
character set identified by SPLN_CHRS of SPLTJ3I- 



2.1.3.4 Playlist Entry Information 





Contents 


Number of Bytes 


(1)PE ST_N 


Index of Stream Title 


2 


(2)PE S SCR 


Start SCR 


6 


(3)PE E SCR 


End SCR 


6 




Total 


14 



(1) PE_ST_N 

Describes the index of the Stream Title to be played back for this PE. 

(2) PE_S_SCR 

Describes the Extended SCR value of the first application packet to be played back. 

(3) PE_E_SCR 

Describes the Extended SCR value of the last application packet to be played back. 



2.1.4 Housekeeping General Information (HKP_GI) 





Contents 


Number of Bytes 


mHAE Ns 


Number of Housekeeping Address Entries 


2 


(2) HKPI EA 


End address of HKPI 


4 


(3) HKP TSCAL 


Time Scale Factor 


1 




Total 


7 



(1) HAE_Ns 

Describes the number of housekeeping address entries countained in this HKPI. The 
maximum allowed number of housekeeping adress entries is TBD. 

(2) HKPI_EA 

Describes the End Address of this HKPI with RBN from the first byte of this HKPI. 
(2) HKP_TSCAL 

Jfecribes the time scaling used within this HKPI. Details of time scaling are TBD. 



2.1.5 Housekeeping Address Table (HAT) 

The purpose of this table is to provide all necessary information so that given playlist 
entries are efficiently translated into disc address pairs (from-to). - BotaNo of HAT oro ^ TBP. 




"Housekeeping" in general context of either RTRW or Stream recording is the 
task to translate a given time value (presentation time in case of RTRW, or 
packet arrival time in case of Stream recording) into a disc address value, 
where the desired data can be found. 



Presentation data in DVD forum's AH1-5's "RTRW Specification" is organized 
into units called "VOBU\ VOBUs are variable size (data amount measured in 
number of sectors), but are also variable duration (measured in number of 
video fields). For data retrieval, i.e. for RTRW's housekeeping, RTRW foresees 
a K VOBU map", which is a table where for every VOBU in a recording, the 
length in sectors, and the duration in fields is entered, by storing these "deltas", 
and not the total length or total duration, these entries can be described with 
smaller wordlength, which helps to keep the total VOBU map in reasonable 
size. 



In Stream recording, bitstreams have no meaning, and we are free to subdivide 
them into sub-units of more regular structure, basically, a table for data 
retrieval can be based on two principles: 

• bitstream data can be subdivided into pieces" of constant "duration" 
or 

• bitstream data can be subdivided into pieces of constant "length" 

in case of bitstream data subdivided into pieces of constant duration, duration 
is the difference between the arrival time of the last packet and the arrival time 
of the first packet of the piece. Then the "housekeeping address table" (HAT) 
contains a size or offset or delta size (in general, an address-like quantity) for 
each of these constant-duration pieces. The housekeeping process then 
consists of the following steps: 

• By division and truncation, calculate from the given time value the index of 
the table entry to look up. 

• The content of the table entry either directly specifies the address value to 
access, or all table entries up to that index have to be accumulated to get 
the address value to access. 

The big disadvantage of a HAT based on constant duration pieces is the 

following fact: 

• In case of a low bitrate recording, the pieces of constant duration will be 
small in size (number of sectors). The disc can contain enormous numbers 
of those pieces, so that the HAT may become unrealistically big (toolig to be 
kept in memory). 
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2.2 Application Private Data 

APD, if it exists, consists of three kinds of information, namely Application Private Data 
General Information (APD_GI), a set of one or more Application Private Data Search 
Pointer (APD_SRP), and a set of one or more Application Private Data Area (APDA). If 
any Application Private Data exists, these three kinds of information shall all mandatorily 
be recorded and stored in the APPLICAT.IFO file in this order. 

NB: Unlike in the "DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION", 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording. 




Figure 2-2 Application Private Data 



2.2.1 Application Private Data General I nformation 

Contents 

Number of Application Private Data Areas 



(1) APDA Ns 



(2) APD EA 



(3) APDA SRVJP 



End Address of Application Private Data 



APD Area Service ID 



Number of Bytes 
T 




APDA Nsx4 



(1) APDA_Ns 

Describes the number of Application Private Data Areas, into which this APD is organized. 

(2) APD_EA 

Describes the end address of APD with RBN from the first byte of the APD. 

(3) APDA_SRV_ID 

Describes a Service ID for each of the Application Private Data Areas to follow. For 
details of Service ID, see Annex A. 

2.2.2 Application Private Data Search Pointer 





Contents 


Number of Bytes 


(1 ) APDA SA 


Start address of APDA 


4 


(1)APDA_SA 
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Describes the start address of APDA with RBN from the first byte of APD. 



2.2.3 Application Private Data Area 



(1) APDA_ 



Contents 
Application Private Data Area 



Number of Bytes 
Variable 



(1)APDA 

Describes the Application Private Data. 
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3 Stream Data Format 

Stream Data according to this Specification consists of one or more .Stream Objects" 
(SOBs) which are each stored as a ..Program stream" as described in [MPEG-2 Systems]. 
A SOB has the following restrictions: 

1. Each SOB shall be terminated by a program__end_code. 

2. The value of the SCR field in the first pack of each SOB may be non-zero. 

A SOB contains the Stream Data packed into a sequence of „Stream Packs" (S_PCKs). 
The transfer rate of SOBs shall obey the restrictions listed in Table 3-1. 
Table 3-1 : Restrictions on transfer rate of Stream Data 



Minimum Transfer rate 


TBD 


Maximum Transfer Rate 


TBD 



Stream Data described under this Specification are organized as one elementary stream 
and are carried in PES packets with a stream_id of of private^ stream_1 . In some other 
formats of the DVD family, private_stream_1 is also used to carry several kind of non- 
MPEG AV Presentation Data. As a means of distinction among these, the first byte of the 
data area of each packet is used as „sub_stream_id tt . DVD Stream Recording, although 
already separated by the use of a different directory for its data, shares this principle, i.e. 
the first byte of data area is used as a sub_stream_id and is entered as a new, unique 
value of TBD designating the subsequent payload as ^Stream Recording Data". 

3.1 Stream Object 

A stream Object is composed of one or more Stream Packs (S_PCKs) as shown in Fig 3-1 



Stream Object (SOB) 




S_PCK 


S_PCK 


S_PCK 


S_PCK 


S_PCK 



S PCK 



Figure 3-1 : Structure of a Stream Object 

Because the length of a SOB is basically arbitrary, the last S_PCK of a SOB might employ 
padding in one of two different ways. For details see Section ??. 

3.2 Stream Pack 

Stream Packs are „Program Stream Packs 11 in the sense of [MPEG2 System] and comply 
with all rules given there. The pack length is 2048 bytes (one LB) and a pack is recorded 
in one LB. 
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A Stream Pack consists of one pack header, followed by zero or one system header, and 
followed by one Stream Packet (S_PKT). An extra padding packet will not be employed, 
as shown in Figure 3-2. 









Pack 
header 


System 
header 4 


Stream Packet 


kbytes 


~24 bytes* 





• may or may not exist 



Figure 3-2 ; Structure of a Stream Pack 

A system header is included exactly in those S_PCKs, which are the first S_PCK of a 
SOB. When a system header is included, the length of the remaining Stream Pack content 
is 2010 bytes, when it is not included, the length of Stream Pack content is 2034 bytes. 

In Stream recording, the application performs its own padding, so that the pack length 
adjustment methods of DVD-ROM Video or RTRW need not to be used. In Stream 
recording it is safe to assume, that the Stream packets will always have the necessary 
length. 

3.2.1 Pack Header 



Table 3-3 : Pack header 

Number 




Field 



k start code 



SCR basef32..301 



marker bit 



SCR base[29..15l 
marker bit 



SCR base[14..0] 
marker bit 



SCR extension 



marker bit 



program_mux_rate 



marker bit 



marker bit 



reserved 

pack stuffingjength 



of bits 



32 



1 



15 



1 



15 



1 



1 



Number 
of bytes 



22 



1 



1 



1 



Value 



0000 01BAh 



provider 
defined 



01 3883h 



F8h 



Comment 



01b 



(Note 1) 



1 



1 



1 



1 



mux_rate - 8Mbps 



(Note 2) 



1 



1 



11111b 



no stuffing length - 000b 



Note 1: „SCR_base[32f shall be set to ZERO. 
Note 2: nprogram^ux^ate" shall be set to 8Mbps. 
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3.2*2 System Header 



Table 3-4 : System header 

Number 



Field 



$y$temheader_start_code 
header length 



marker_bit 



rate_bound 



marker_bil 



audio_bound 



fixedjlag 



CSPSJag 



systerq.audioJock_flag 



system_videoJock_flag 



marker_bit 



video bound 



of bits 



32 



16 



22 



1 



1 



1 



1 



Number 
of bytes 



Value 



OOOOOIBBh 



809C41h 



1or0 



1 



1 



1 



Comment 



1 



mux_rate = 8Mbps 



1 



No audio streams 



Variable bit rate 



1 



1 



No video streams 




packeLrate_restriction_flag 
reserved_bHs 



1 



0or1 



7Fh 



streamjd 



8 



•11' 



11b 



P-STP_buf_bound_scale 



1 



P-STD_buf_size_bound 
streamjd 



13 



8 



'11' 



P-STD_buf_bound_scale 



1 



P-STD_buf_size_oound 
streamjd 



13 



8 



•ir 



P-STD buf_bound_scale 



1 



P-STD_buf_size_bound 
streamjd 



•11' 



P-STD buf_bound _scale 
P-STD_buf,size_bound 



13 



8 



13 



1 



1 



1 



buf size x 1 024 bytes 



232* 



buf _size = 237568 bytes 



11b 



buf_size x 1 28 bytes 



32 



bufjsize - 4096 bytes 



1011 1101b 



private j>tream_1 



11b 



1 



buLsize x 1024 bytes 



58 



bjf size = 55392 bytes 



10111111b 



private _stream_2 



11b 



1 



buf_size x 1024 bytes 



buLsize ~ 2048 bytes 



3.3 Stream Packet 

In Stream Packets, no stuffing takes place and each Stream packet has just DTS, no PTS. 
Packet header size therefore is 14 bytes constant. 
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3.3.1 Packet Header 



Field 


Numoer 

nf hit* 


Number 
of bytes 


Value 


Comment 


packet start code prenx 


ac** 


3 


00 0001 h 




stream id 


Q 


1 


1011 1101b 


private stream 1 


PES packet Jengtn 




2 






10 




3 


10b 




PES scramDlin9 coniroi 


n 
«£ 




TBD 


PES priority 




n 


no Drioritv 


data alignment indicator 


-j 


n 

w 


not defined bv descriotor 


copyright 


1 


n 


not defined bv descriotor 


original or copy 





n 
u 




PTS DTS flags 


~ 






F&CR flap 




0 


nn F9CR field 


Borate fla^ 





0 


no P5> rafo fiplri 


DSM trick mode flag 


~ 


0 


nr\ trinlf mnHo fiolH 


additional copy info flag 




0 


nn i-'fwwj i irfo fi olrH 

no wupy if iiw iieivi 


PES CRC flap 




0 


nn PRP fi*alH 


PES extension flag 





0 


nn ovtonc'mn 


PES header data length 


8 


c 
O 




'0001' 


4 


5 


Provider 
defined 




DTSr32..301 


3 




marker bit 


1 


- 


DTSl2y..ioj 






marker bit 


1 




DTSH4..0] 


15 




marker bit 


1 




stuffing byte m 

etrpam id 


I 8 
Stream < 


0to7 
Priv, 

I 1 

data area 


ate data area 
|TBD 


1 



3.3.2 Stream Data area 

The Stream data area inside a Stream Packet consists of an application header, an 
application header extension, and a sequence of application packets, each prefixed by an 
application packet timestamp. 



3.3-2.1 Application Header 



Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


(1) MAX B URATE 


32 


4 






(2) SMOOTH BUF SIZ 


16 


2 


3540 bytes 




(3)TS REF CL FREQ 


32 


4 


27 MHz 




(A)AP PKT LEN 


16 


2 






(5)TS LEN 


8 


1 


'4' 




(6)AP PKT Ns 


8 


1 






(7) START OF STR 


1 


1 


Ob or 1b 




(8) END OF STR 


1 


Ob or 1b 




reserved 


6 








Total 


15 







(1) M ARBITRATE 

Describes the output bitrate parameter of the leaky bucket flow control model in Mbps. 

(2) SMOOTH_BUF_SIZ 

Describes the buffer size parameter of the leaky bucket flow control model. 

(3) TS_REF_CL_FREQ 

Describes the reference clock frequency of the packet arrival/delivery timestamp. 

(4) AP_PKT_LEN 

Describes the length of the application packet. 

(5) TS_LEN 

Describes the length of the timestamp field. 

(6) AP_PKT_Ns 

The number of application packets in this DVD pack. 

(7) START_OF_STR 

When set to '1 \ this packet is the first DVD pack in the stream. 

(8) END_OF_STR 

When set to '1 this packet is the last DVD pack in the stream. 



3.3.2.2 Application Header Extension 

The application header extension consists of a list of entries, where there is exactly one 
entry for each transport layer packet. These bytes are used to store information that may 
differ from packet to packet. 

The total length of the application header extension shall be 46 bytes. The first 
'AP_PKT_Ns' entries of these shall carry valid data. Unused list entries may carry 
undefined values. 

The total length of 'application header 1 and 'application header extension' shall be 61 
bytes. 
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Field 



(1) AU_START 

(2) AU_END 

(3) reserved 
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GERMAN 

TS GERffflY 



Number 
of bits 



1 
T 
4 




Number 
of bytes 



1 




• ••• 




— • 



TH OMSON multimod i a C o nfidontia l -7 



Value 



Comment 



(1)AU_START 

When set to '1', indicates that the associated application packet contains a random 
access entry point into the stream 

(2LAU END 

\flPfen set to '1 indicates the associated application packet is the last packet of a random 
access point 

(4) COPYRIGHT 

Describes the copyright status of the associated application packet. Octails-arc TBD 
5.5- 2.3 Time Stamps 




List of Abbreviations 



LB Logical Block 

RBN Relative Byte Number 



RBP Relative Byte Position 

RLBN Relative Logical Block Number 
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Claim 



1. Method for addressing a bitstream to be recorded or being 
recorded on a storage medium, e.g. a DVD recorder, 
wherein an address table is used that is based on pieces 
of said bitstream including a constant amount of bits, to 
each of which pieces an absolute time duration or delta 
time duration is assigned in said address table. 
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